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(57) ABSTRACT 

A system and method for creating a graphical program, 
wherein the graphical program is operable to invoke execu- 
tion of textual code. The user selects a code node for 
inclusion in the graphical program, wherein the code node is 
displayed on the screen. The user then selects or enters 
textual code that is comprised in or displayed in the code 
node. The textual code may be code from a text-based 
language, such as Perl, Mathematica, or Java, etc., or may be 
a script from a scripting language. The user may manually 
enter the textual code into the code node, or import the 
textual code from a file. The textual code comprised in the 
code node is user viewable and editable. During execution 
of the graphical program, the code node is operable to 
invoke execution of the textual code comprised in the code 
node. The textual code is preferably executed by an instance 
of a server program. During execution of the graphical 
program, the graphical programming system provides the 
textual code to the server program, as well as any input data 
received by the code node. The server program then 
executes the textual code, using any input data received by 
the code node, and produces an output which is provided 
back to the graphical program. The present invention thus 
enables a user of a graphical programming system to more 
easily incorporate, view, edit and debug textual based code 
from within the graphical programming system. 

28 Claims, 15 Drawing Sheets 
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CODE NODE FOR A GRAPHICAL 
PROGRAMMING SYSTEM WHICH 
INVOKES EXECUTION OF TEXTUAL CODE 

MICROnCHE APPENDIX 

The present disclosure includes a microfiche appendix 
comprising 2 microfiche and 86 frames. The microfiche 
appendix comprises appendix A, which contains source code 
listings of one embodiment of the present invention. 

RESERVAnON OF COPYRIGHT 

A portion of the disclosure of this patent document 
contains material to which a claim of copyright protection is 
made. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark OfQce 
patent file or records, but reserves ail other rights whatso- 
ever. 

FIELD OF THE INVENTION 

The present invention relates to graphical programming, 
and in particular to a system for creating and executing 
graphical programs including a code node^ wherein the code 
node in the graphical program contains textural source code 
which is viewable and editable by a user and is executed 
during execution of the graphical program. 

DESCRIPTION OF THE RELATED ART 

Traditionally, high level text-based programming lan- 
guages have been used by programmers in writing applica- 
tions programs. Many different high level programming 
languages exist, including Perl, Mathcmatica, Java, Basic, 
C, C++, Fortran, Pascal, Cobol, ADA, APL, etc. Programs 
written in these high level languages are translated to the 
machine language level by translators known as compilers. 
The high level programming languages in this level, as well 
as the assembly language level, are referred to as text-based 
programming environments. 

Increasingly computers are required to be used and pro- 
grammed by those who are not highly trained in computer 
programming techniques. When traditional text-based pro- 
gramming enviromnents are used, the user's programming 
skills and abiUty to interact with the computer system often 
become a limitiTig factor in the achievement of optimal 
utilization of the computer system. 

There are numerous subtle complexities which a user 
must master before he/she can e£5ciently program a com- 
puter system in a text-based environment. The task of 
programming a computer system to model a process often is 
further complicated by the fact that a sequence of math- 
ematical formulas, mathematical steps or other procedures 
customarily used to conceptually model a process often does 
Qot closely correspond to the traditional text-based program- 
ming techniques used to program a computer system to 
model such a process. In other words, the requirement that 
a user program in a text-based programming environment 
places a level of abstraction between the user's conceptu- 
alization of the solution and the implementation of a method 
that accomplishes this solution in a computer program. 
Thus, a user often must substantially master different skills 
in order to both conceptually model a system and then to 
program a computer to model that system. Since a user often 
is not fully proficient in techniques for programming a 
computer system in a text-based environment to implement 
his model, the efficiency with which the computer system 
can be utilized to perform such modeling often is reduced. 
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Examples of fields in which computer systems are 
employed to model and/or control physical systems arc the 
fields of instramcntation, process control, and industrial 
automation. Computer modeling or control of devices such 

5 as instruments or industrial automation hardware has 
become increasingly desirable in view of the increasing 
complexity and variety of instruments and devices available 
for use. However, due to the wide variety of possible 
testing/control situations and environments, and also the 

10 wide array of instruments or devices available, it is often 
necessary for a user to develop a program to control a 
desired system. As discussed above, computer programs 
used to control such systems had to be written in conven- 
tional text-based programming languages such as, for 

15 example, assembly language, C, Fortran, Basic, Pascal, Perl, 
Mathematica, or Java. Traditional users of these systems, 
however, often were not highly trained in programming 
techniques and, in addition, traditional text-based program- 
ming languages were not suffidendy intuitive to allow users 

2Q to use these languages without training. Therefore, imple- 
mentation of such systems frequently required the involve- 
ment of a programmer to write software for control and 
analysis of instrumentation or industrial automation data. 
Thus, development and maintenance of the software ele- 

25 ments in these systems often proved to be difficult. 

U.S. Pat. No. 4,901,221 to Kodosky et al discloses a 
graphical system and method for modeling a process, ie., a 
graphical programming environment, which enables a user 
to easily and intuitively model a process. The graphical 

30 programming environment disclosed in Kodosky et al can be 
considered the highest and most intuitive way in which to 
interact with a computer. A graphically based programming 
envirorunent can be represented al level above text-based 
high level programming languages such as C, Pascal, etc. 

35 The method disclosed in Kodosky et al allows a user to 
construct a diagram using a block diagram editor, sudi that 
the diagram created graphically displays a procedure or 
method for accomplishing a certain result, such as manipu- 
lating one or more input variables to produce one or more 

40 output variables. After the user constructs a data flow 
diagram or graphical program using the block diagram 
editor, machine language instructions are automatically con- 
stracted which characterize an execution procedure which 
conesponds to the displayed procedure. Therefore, a user 

45 can create a computer program solely by using a graphically 
based programming environment. This graphically based 
programming environment may be used for creating virtual 
instrumentation systems, industrial automation systems and 
modeling processes, as weU as for any type of general 

50 programming. 

Therefore, Kodosky et al teaches a graphical program- 
ming environment wherein a user places or manipulates 
icons in a block diagram using a block diagram editor to 
create a data flow "program.** A graphical program for 

55 controlling or modeling devices, such as instruments, pro- 
cesses or industrial automation hardware, is referred to as a 
virtual instrument (VI). In creating a virtual instrument, a 
user preferably creates a graphical user interface, e.g., a front 
panel or user interface panel. The graphical user interface 

60 (GUI) includes various froiU panel objects, such as controls 
or indicators that represent the respective input and output 
that will be used by the graphical program or VI, and may 
include other icons whidi represent devices being con- 
trolled. When the controls and indicators are created in the 

65 GUI or front panel, corresponding icons or terminals are 
automatically created in the blocJc diagram by the block 
diagram editor. Alternatively, the user can first place termi- 
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nal icnns in the block diagram which cause the display of graphical program is operable to incorporate textTial code 

corresponding front panel objects in the GUI or front panel. and is operable to invoke execution of textual code. The 

The user then chooses various functions that accomplish his method ioi creating the graphical program operates in a 

desired result, connecting the corresponding function icons computer including a display screen and a user input device, 
between the terminals of the respective controls and indi- 5 jhe method for creating the graphical program includes 

cators. In other words, the user creates a data flow program, the user selecting a code node for inclusion in the graphical 

referred to as a bbck diagram, representing the graphical program, wherein the code node is displayed on the screen, 

data flow which accomplishes his desired function. This is The user then selects or enters textual code that is comprised 

done by wiring up the various function icons between the jn or displayed in the code node. The textual code may be 
control icons and indicator icons. The manipulation and lo code from a text-based language, such as Perl, Mathematica, 

organization of icons in turn produces machine language or Java, or may be code such as C, C++, Pascal, Fortran, 

that accomphshes the desired method or process as shown in Cobol, etc., or may be a script from a scripting language. The 

the block diagram. user may manually enter the textual code into the code node, 

Auser inputs data to a virtual instrument using front panel or import the textual code from a file. The textual code 

controls. This input data propagates through the data flow comprised in the code node is user editable. In creating the 

block diagram or graphical program and appears as changes graphical program, the user ananges a plurality of nodes on 

on the output indicators. In an instrumentation application, the screen, including the code node, preferably by connect- 

the front panel can be analogized to the front panel of an ing the nodes in a data flow format. During execution of the 

instrument. In an industrial automation application the front graphical program, the code node is operable to invoke 
panel can be analogized to the MMI (Man Machine 20 execution of the textual code comprised in the code node. 
Interface) of a device. The user adjusts the controls on the jn the preferred embodiment, the textual code is executed 

front panel to aflfecl the input and views the ou^ut on the by an instance of a server program. In one embodiment, the 

respective indicators, user selects a particular code node depending on the type of 

Thus, graphical programming has become a powerful tool textual code and the corresponding server program required, 
available to programmers. Graphical programming environ- ^ and the server program is selected based on the type of the 

ments such as the National Instruments LabVIEW product code node. During execution of the graphical program, the 

have become very popular. Tools such as LabVIEW have graphical programming system provides the textual code to 

greatly increased the productivity of programmers, and the server program. If the code node is connected to receive 

increasing numbers of programmers are using graphical inputs from one or more nodes in the graphical program, the 
programming environments to develop their software appli- ^ graphical programming system also provides this input data 

cations. In particular, graphical programming tools are being to the server program. The server program then executes the 

used for test and measurement, data acquisition, process textual code, using any input data received by the code node, 

control, man machine interface (MMI), and supervisory and produces an output. The server program provides this 

control and data acquisition (SCADA) applications, among output to the graphical program, and the output is used 

others. during subsequent execution of the graphical program. For 

It is desirable for a program, such as a graphical program, example, if the code node is connected to provide an output 

to be able to access functionality provided by a text based to one or more other nodes, the output produced by the 

program, such as a program written in C, C++, Basic, Pascal, server program is provided to these one or more other nodes. 
Fortran, Cobol, or a scripting language, among others. It is ^ Upon completion of the graphical program, the instance of 

further desirable to enable a user to be able to create, view the server program is released. 

and/or edit textual code in a graphical program. Therefore, The present invention thus enables a user of a graphical 

improved methods are desired for enabling a graphical data programming system to more easily incorporate, view, edit, 

fiowprogramming system lo incorporate or invoke text code debug and invoke textual based code from within the 

programs, including scripts. graphical programming system. 

Prior versions of LabVIEW included a code interface 
node (ON). The QN is a block diagram node associated ^RIEF DESCRIFIION OF THE DRAWINGS 

jj - - - o T — 

/ the source code first and linked it to form executable code.. 50 preferred embodiment is considered in conjunction with the 
A LabVEEW VI then called the executable code when the \ following drawings, in which: 
CIN node executed, passing input data from the block 
diagram to the executable code and returning data from the 
executable code to the blodc diagram. The code interface 



teth, a section of source code written in a conventional a better understanding of the present invention can be 
^oQgfogramming language, i.e., text code. The user compiled obtained when the following detailed description of the 



FIG. 1 illustrates an instrumentation control system 
according to one embodiment of the present invention; 

node could only be used to invoke execution of executable ^ iiliistrates an industrial automation system 

code. Further, a code interface node in a graphical program / embodmient of the present mvention; 

could not be used to directly view or edit the code which was/ FIG. 2 is a block diagram of the computer of the control 

called by the code interface node. i system of FIG. 1; 

Prior versions of LabVIEW also induded a formula node? FIG. 3 is a flowchart diagram illustrating creation of a 

The user could input a formula into the formula node, and 60 graphical program including a code node according to the 

during executing of the graphical program, execution of the present invention; 

formula node resulted in execution of the formula contained FIG. 4 is a flowchart diagram illustrating compilation of 

within the formula node. / the graphical program created in FIG. 3; 

cr iMx/ ADv nc tut: ixn/CKrrrriM ^IG. 5 is a flowchart diagram iflustrating execution of the 

SUMMARY OF THE INVENTION j gn^phical program created in RG. 3 and compiled in HG. 4, 

The present invention comprises a computer system and wherein the code node operates to access and execute 

method for creating a graphical program, wherein the external code; 
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FIG. 6 illustrates the relationship of the graphical pro- The one or more iostniments may include a GPIB instru- 

gramming system and the various DLLs; mcnt 112 and associated GPIB interface card 122, a data 

FIG. 7 is a more detailed diagram illustrating how code acquisition board 114 and associated signal conditioning 

nodes access the various DLLs; circuitry 124, a VXI instrument 116, a PXI instrument 118, 

HG. 8 is a screen shot ilhistrating the user selecting a ' ^^^^^^eo device 132 and associated image acquisition card 

MatLab script node from the function palette of the graphi- \ ""ot^"^ control device 136 and associated motion 

cal programming system; "^^^^^ mterface card 138, and/or one or more computer 

™^ ft . u * It, * *u \ji w • ♦ j« based instrument cards 142, among other types of devices. 

FIG. 9 IS a screen shot illustrating the MatLab scnpt node . ' . , / . ^ 

placed on the block diagram; GPEB instrument 112 is coupled to the computer 102 

T-Fo -1ft - I- * 11 * *- *u - , 10 via the GPIB interface card 122 provided by the computer 

FIG. 10 IS a screen shot lUustratmg the user adding mputs ^ • -i .l j j • ^i-* • i 

, - ^ . . • . J 102. In a similar manner, the video device 132 is coupled to 

and/or outputs to the scnpt node; the computer 102 via the image acquisition card 134, and the 

HG- 11 IS a screen shot flhistrating the user selecting a ^^^^^ ^^^^^^ ^^^.^^ ^^^^^ ^ computer 102 

data type for mputs and/or outputs of the scnpt node; ^^^^^ ^^^^^ ^^^^^ ^^^^^^ ^ 13g 

FIG. 12 is a screen shot ilhistrating the nser connecting 15 acquisition board 114 is coupled to the computer 102, and 

terminals of the script node to the rest of the diagram; preferably interfaces through signal conditioning circuitry 

FIG. 13 is a screen shot illustrating a user typing in code, 124 to the UUT. The signal conditioning circuitry 124 

such as a script, into the script node, as well as the user preferably comprises an SCXI (Signal Conditioning exten- 

importing code from another source; sioos for Instrumentation) chassis comprising one or more 

FIG. 14 is a screen shot illustrating execution of a 20 sCXI modules 126. 

graphical program including a MatLab script node; and The GPIB card 122, the image acquisition card 134, the 

FIG. 15 is a table illustrating corre^ondence of data types motion control interface card 138, and the DAQ card 114 are 

between LabVEEW, HiQ and MatLab, typically plugged in to an I/O slot in the computer 102, such 

While the invention is susceptible to various modifica- as a PQ bus slot, a PC Card slot, or an ISA, EISA or 

tions and alternative forms specific embodiments are shown ^ MicroChannel bus slot provided by the computer 102. 

by way of example in the drawings and will herein be However, these cards 122, 134, 138 and 114 are shown 

described in detail. It should be understood however, that external to computer 102 for ilhistrative purposes, 

drawings and detailed description thereto are not intended to The VXI diassis or instrument 116 is coupled to the 

limit the invention to the particular form disclosed. But on computer 102 via a VXI bus, MXI bus, or other serial or 

the contrary the invention is to cover aU modifications, ^ parallel bus provided by the computer 102. The computer 

equivalents and alternative following within the spirit and 102 preferably includes VXI interface logic, such as a VXI, 

scope of the present invention as defined by the appended MXI or GPIB interface card (not shown), which interfaces 

claims. to the VXI chassis 116. The PXI chassis or instrument is 

preferably coupled to the computer 102 through the com- 

DETAILED DESCRIPTION OF THE 35 

PREFERRED EMBODIMENT ^ ^^^^ instrument (not shown) may also be coupled to 

Incorporation by Reference ^« computer 102 through a serial port, such as an RS.232 

^ ^ port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 

ITie following U.S. Patents and patent applications are ^^s, provided by the computer 102. In typical instrumenta- 

hereby incorporated by reference in their entirety as though ^ tion control systems an instrument will not be present of 

fiilly and completely set forth herein. ^g^h interface type, and in fact many systems may only have 

U.S. Pat. No. 4,901,221 titled "Graphical System for one or more instruments of a single interface type, such as 

Modeling a Process and Associated Method," issued on Feb. only GPIB instruments. 

13, 1990. -fhe instruments are coupled to the unit under test (UUT) 

U.S.Pat. No. 5,481,741 titled "Method and Apparatus for or process 150, or are coupled to receive field signals. 

Providing Attribute Nodes in a Graphical Data Flow Envi- typically generated by transducers. The system 100 may be 

ronment". used in a data acqiusition and control application, in a test 

The Lab VIEW and Bridge VIEW graphical programming and measurement application, a process control application, 

manuals and help files, including the "G Programming 50 or a man-machine interface application. 

Reference Manual", available from National Instruments FIG. lA illustrates an industrial automation system 160. 

Corporation, are also hereby incorporated by reference in The industrial automation system 160 is similar to the 

their entirety. instrumentation or test and measurement system 100 shown 

.T^.-, in FIG. 1. Elements which arc similar or identical to cle- 

FIGS. 1 and lA — Instrumentation and Industnal . i l *i. r i c 

X L^^. X aii« xj-i. iuoiiuxuviiv<i iv/ii auv* mcuts lu FIG. 1 hav6 thc same reference numerals for 

Automaton Systems convaiicnce. Hie system 160 comprises a computer 102 

FIGS. 1 and lA illustrate example systems where thc whidi connects to one or more devices or instruments. Thc 

present invention may be used. The present invention may of computer 102 comprises a CPU, a display screen, memory, 

course be used in other types of systems as desired. and one or more input devices such as a mouse or keyboard 

FIG. 1 illustrates an instrumentation control system 100. 60 as shown. TTic computer 102 connects through the one or 

The system 100 comprises a host computer 102 which more devices to a process or device 150 to perform an 

connects to one or more instruments. The host computer 102 automation function, such as MMI (Man Machine 

comprises a CPU, a display screen, memory, and one or Interface), SCAD A (Supervisory Control and Data 

more input devices such as a mouse or keyboard as shown. Acquisition), portable or distributed data acquisition, pro- 

The computer 102 connects through the one or more instru- 65 cess control, advanced analysis, or other control. 

ments to analyze, measure or control a unit under test (UUl^ The one or more devices may include a data acquisition 

or process 150. board 114 and associated signal conditioning circuitry 124, 
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a PXI instnimcnt 118, a video device 132 and associated Although in the preferred embodiinent the graphical pro- 
image acqiiisition card 134, a motion control device 136 and gramming system is involved with data acquisition/ 
associated motion control interface card 138, a fieldbus generation, analysis, and/or display, and for controlling or 
device 170 and associated fieldbus interface card 172, a PLC modeling instrumentation or industrial automation 
(Programmable Log;ic Controller) 176, a serial instrument 5 hardware, it is noted that the present invention can be used 
182 and associated serial interface card 184, or a distributed fo^ ^ plethora of applications and is not limited to instm- 
data acquisition system, such as the Ficlc^int system mentation or industrial automation applications. In other 
available fxom NaUonal Instruments, among other types of pjQs 1 and lA are exemplary only, and the present 
devices. ^ . invention may be used in any of various types of systems. 

The DAQ card 114, the PXI diassis 118, the video device j^^^ ^^^^ ^^^^^ p^s^nt invention is 

132, and the image acquisition card 136 are preferably ^ ^^^^j^ graphical programs or graphical code 

connected to the computer 102 as described above. Hie ^^^^ appUcations, inchiding general 

serial mstrument 182 IS coupled to the computer 102 through v u -j 

a serial interface card 184, or through a serial port, sucfals P^^, ^^^^^f apphcaUons such as word processmg, 

an RS.232 port, provided by the computer 102. Tlic PLC spreadsheets, network control, games, etc. 

176 couples to the computer 102 through a serial port, 2— Computer Block Diagram 
Ethernet port, or a proprietary interface. The fieldbus inter- 

face card 172 is preferably comprised in the computer 102 FIG. 2 is a representative block diagram of the host 

and interfaces through a fieldbus network to one or more computer 102 (of HG. 1). It is noted that the block diagram 

fieldbus devices. Each of the DAQ card 114, the serial card of HG. 2 is representative only, and the computer 102 may 

184, the fieldbus card 172, the image acquisition card 134, 20 have any of various architectures. Also, the elements of a 

and the motion control card 138 are typically plugged in to computer not necessary to understand the operation of the 

an I/O slot in the computer 102 as described above, present invention have been omitted for simplicity. 

However, these cards 114, 184, 172, 134, and 138 are shown „ ^ in-? ^r.^ r^^t.,\ „w,^^ce;«r. 

, ' * r Ml . T * • 1 Ine computer 102 mcluoes at least one central processing 

external to computer 102 for illustrative purposes. In typical -iaa u - l • 1 j * u * 

industrial automation systems a device not be pre^nt of 25 or CPU 200 which ^^^^ 

eachinterfacetype,andinfactmanysystemsmay onlyhave ^02, ^e CPU 200 may be any of vanous types mcluding 

one or more devices of a single interface type, such as only processor, a PowerPC proce^r, a CPU from die 

PLCs. The devices are coupled to the device or process 150. Motorola Canily of processors, a CPU from the SPARC 

Referring again to FIGS. 1 and lA, the computer system 102 f^^i^y of ^^C processors, as well as others. Main memory 

preferably inchides a memory media on which computer 30 ^ coupled to the host bus 202 by means of memory 

programs according to the present invention are stored. The controDer 204. The main memory 206 stores a graphical 

term "memory media" is intended to include an installation programming system. The main memory 206 also stores 

media, e.g., a CD-ROM, or floppy disks 104, a computer operating system software as wcfl as other software for 

system memory such as DRAM, SRAM, EDO RAM, etc., operation of the computer system, as well known to those 

or a non-volatile memory such as a magnetic media, e.g., a 35 s^^l^d in the art. The instrumentation control software will 

hard drive, or optical storage. The memory media preferably be discussed in more detail below. 

stores a graphical programming development system for The host bus 202 is coupled to an expansion or input/ 

developing and executing graphical programs. The created output bus 210 by means of a bus controller 208 or bus 

graphical programs may include one or more code nodes, bridge logic. The expansion bus 210 is preferably the PCI 

also called script nodes, which are operable to view, edit and 40 Peripheral Component Interconnect) expansion bus, 

invoke execution of code, such as text code, e.g., a script. although other bus types can be used. The expansion bus 210 

The host CPU executing code and data from the memory includes slots for various devices such as the data acquisi- 

comprises a means for creating and executing graphical tion board 114 (of FIG. 1), the GPIB interface card 122 

programs according to the methods described below. which provides a GPIB bus interface for coupling to the 

Ihe instruments or devices in FIGS. 1 and lA arc con- 45 GPIB instrument 112 (of FIG. 1), and a VXI or MXI bus 

trolled by graphical software programs. Graphical software card 186 for coupling to the VXI chassis 116 for receiving 

programs which perform data acquisition, analysis and/or VXI instruments. 

presentation, e.g., for instrumentation control or industrial The computer 102 firdicr preferably comprises a video 

automation, are referred to as virtual instruments. display subsystem 220 \^idi interfaces to video monitor 

In the preferred embodiment, the present invention uti- 50 222, and a non-volatile memory such as hard drive 224, each 

lizes the Lab VIEW or Bridge VIEW graphical programming preferably coupled to the expansion bus 210. The computer 

systems, hereafter collectively referred to as Lab VIEW, 102 further preferably comprises various input devices, such 

available from National Instruments. Also, in the preferred as mouse 230 and keyboard 232, as shown. The input 

embodiment, the term "Lab VIEW* is intended to include devices are shown coupled to the expansion bus 210, but 

graphical pro^amming systems which include G program- 55 may be connected to the computer in any of various ways, 

ming functionality, i.e., which include at least a portion of such as a USB port (not shown). TTie computer 102 further 

LabVIEW graphical programming functionality, including preferably comprises various other standard components, as 

the BridgeVIEW graphical programing system. is well known in the art. 

Also, the term "graphical programming system" is i-. u- 1 n * o . 

intended to include any of various types of systems which 60 Graphical Programmmg System 

are used to develop or create graphical code or graphical As noted above, in the preferred embodiment the present 

programs, including LabVIEW and BridgeVIEW from invention utilizes the LabVIEW graphical programming 

National Instruments, Visual Designer from Intelligent system. A graphical program created using LabVIEW may 

Instnmientation, Hewlett-Packard's VEE (Visual Engineer- comprise an instrument firant panel in a first window and a 

ing Environment), Snap-Master by HEM Data Corporation, 65 bloci diagram in a second window. The block diagram 

DASYLab by DasyTec, GFS DiaDem, and GEDAE, among comprises program execution elements, referred to as nodes, 

others. which are wired or linked together to produce a data flow 
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program. The front panel comprises cootrols for providing the textual code. Thus, if the code node is a HiQ script node, 

input data to the block diagram and indicators for receiving the graphical programming system loads the DLL corrc- 

and/or dispbying output data from the nodes of the blodc spending to HiQ. If the code node is a MatLab script node, 

diagram. Certain drawings in the present disclosure com- the graphical programming system loads a Mat Lab DLL of 

prise screen shots displayed during the execution of Lab- 5 the script node. The operation of the DLL is discussed 

VIEW according to the present invention. further bebw. 

In the preferred embodiment, a programmer employs a In step 308 the user connects the code node to the rest of 

front panel editor, a block diagram editor, and optionally a the graphical program. In step 308 the user may anange the 

connector paneAcon editor of a graphical programming graphical program on the screen, including the code node, 

environment to produce the graphical program. In the instru- lO xhe graphical program will typically comprise a plurality of 

mentation application of the preferred embodiment, the nodes, and the method for creating the graphical program 

graphical program is referred to as a virtual instrument (VI). preferably comprises arranging on the screen the plurality of 

The block diagram editor generates executable instructions, nodes, including the code node, and connecting the various 

i.e., machine language instructions, in response to the VI. nodes to create the graphical program. In the preferred 

The VI developed by the programmer is executed by an embodiment, the nodes are connected in a data flow 

execution subsystem of the graphical programming envi- paradigm, wherein nodes include inputs and outputs, and 

roimient to control an instrument. The instrument is iUus- each node receives input data from another node, or from an 

trative of instruments such as those of FIGS. 1 and lA. input user interface node or terminal, and each node pro- 
vides output data to another node, or to an output user 

FIGS. 3-5: Creation and Execution of a Graphical 20 interface node or terminal. In the preferred embodiment, the 

Program Including a Code Node ^^ser right clicks or "pops up" on the code node to add inputs 

FIG. 3 is a flowchart diagram iUustrating creation of a and/or outputs to the code node for connecting to other 

graphical program including a code node according to the nodos in the graphical program. 

preferred embodiment. It is noted that various of the steps in FIG. 10 is a screen shot illustrating the user adding inputs 

the flowcharts of FIGS. 3-5 can be performed concurrently ^ and/or outputs to the script node. FIG. 11 is a screen shot 

or in different orders. The present invention includes the use illustrating the user selecting a data type for inputs and/or 

of a function node, referred to as a "code node", whidi is outputs of the script node. FIG. 12 is a screen shot iUus- 

operable to invoke execution of code comprised within the trating the user connecting terminals of the script node to the 

code node. Where the code node is used to invoke execution rest of the diagram. 

of a script, the code node is referred to as a script node. Thus ^ in step 310 the user creates or selects code (sotirce code), 

a script node is a particular example of a code node that is e.g., a script, for the code node. For example, in one 

used for creating and/or invoking execution of a script from embodiment, the user can simply enter code or a script into 

a scripting language. the code node. For example, the user can simply type C, 

As shown, during creation of the graphical program, in C+4, or Java code (or othot types of textual code), directly 

step 302 the user operates to place a code node in the into the node to perform any desired task Also, for example, 

graphical program. Stated another way, during program the user can directly type a HiQ script or a MatLab script, 

creation the computer system displays on the screen a code among others, directly into the node. The user enters the 

node in the graphical program in response to user input. In code or script using an irq)Ut device, such as a keyboard, 

the preferred embodiment, the user drags the code node from ^ mouse, or using speech recognition. Alternatively, or in 

a palette onto the graphical program window. FIG. 8 is a addition, the user can select an import feature to import 

screen shot illustrating the user selecting a MatLab script source code from another source, e.g., from a file on the 

node from the function palette of the graphical programming computer, into the code node. In this instance, the user 

system. FIG. 9 is a screen shot iUustrating the MatLab script preferably right clicks on the code node and selects an 

node placed on the block diagram. "import code" feature. This causes textual source code to be 

The code node may be for referencing external code of imported from another source and inserted directly into the 

various types, such as Perl, Mathematica, or Java code, or C, code node. After being input by the user or being imported, 

C++, Basic, Pascal, Fortran, or Cobol source code, among the code is viewable or displayed in the code node and is also 

others. In the current embodiment, the code node is used for user editable in the code node. The user is thus able to 

executing scripts from either the MatLab or HiQ programs. 50 immediately view the code entered into the code node for 

In this embodiment, the code node is referred to as a script easy debugging. It is noted that step 310 may be performed 

node. Also, in this embodiment, the script node may be one before step 308, as desired. 

of a HiQ script node or a MatLab script node. FIG. 13 is a screen shot illustrating the user typing a script 

In step 304 the graphical programming system examines directly into the code node and/or importing code, e.g., a 

the code node to determine which type of code node was 55 scrq)t, from another source. In FIG. 13, the user has typed in 

dropped. In the preferred embodiment, the graphical pro- the script: "c-a * b;" directly into the code node. Also, FIG. 

gramming system examines a string associated with or 13 illustrates the user selecting an "Import ..." feature to 

comprised in a code node to determine the type of code node import code into the code node. 

that was dropped. In an alternate embodiment, the graphical in step 312 the user optionally tests the code node. In this 

programming system includes a single type of code node, so embodiment, when the user selects the option to test the 

and the user selects the desired server program for the code code node, a window "pops up" which enables the user to 

node. edit, compile and run the code or script directly from an 

In step 306 the graphical program programming system application (the server program) to oisure that the code or 

bads an appropriate dynamic linked library (DLL) for the script behaves properly. For example, if the code comprised 

code node, based on the determination performed in step 65 in the code node is a HiQ script, the user selection of the test 

304. The DLL is used for interfacing between the code node option enables the user to edit, compile and run the script 

and the respective server program which actually executes directly from the HiQ application to ensure that it behaves 
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properiy. Similaily, if the code node comprises a MatLab 
script, user selection of this option allows the user to edit, 
compile and nin the MatLab script direcQy from the MatLab 
application to ensure proper behavior. If the code node 
comprises text based code, such as C or C++ code, an 
appropriate compiler appUcation is launched, such as Lab- 
Windows CVI, \%ual Basic, Delphi, etc., which enables the 
user to edit, compile and run the source code directly from 
the respective application to ensure proper behavior. 

In the preferred embodiment, the graphical program com- 
prises a diagram or execution portion and a user interface 
portion, and the code node is comprised in the diagram 
portion. Creation of the graphical program thus may also 
include configuring a user interface to display data input to 
and/or output from the graphical program. In one 
embodiment, such as the Lab VIEW graphical programming 
system from National Instruments, the user may separately 
configure or assemble a user interface panel including user 
interface nodes, such as dials, switches, charts, graphs, etc. 
In this embodiment, terminals which coaespond to each of 
the user interface nodes appear in the block diagram and 
operate to provide or represent data input to/output from the 
block diagram. In another embodiment, the user assembles 
user interface nodes into the block diagram with the function 
nodes, wherein the user interface nodes have associated user 
interface elements, such as dials, sliders, text boxes, graphs, 
charts, etc. The user may then selectively view the user 
interface elements associated with each of the user interface 
nodes, such as in Hewlett Packard's VEE product. 
Alternatively, the user interface panel is automatically con- 
structed from the user interface nodes in the block diagram, 
such as in the Visual Designer product from Intelligent 
Instrumentation. 

Once the graphical program has been created, then the 
graphical program may tben be compiled into machine 
language instructions for execution. The graphical program 
may also be interpreted, as desired. In the preferred 
embodiment, when the user selects "tun^, the graphical 
program is compiled into machine language instructions and 
the machine language instructions are then executed. 

As shown, during compilation, in step 342 the system/ 
method constmcts execution instructions in response to the 
graphical program. This includes constructing execution 
instructions corresponding to the code node in the graphical 
program. 

In step 344 the system/method initiates a new instance of 
the code server for the corresponding program or application 
also referred to as the server program. For example, where 
the code comprised in the code node is a HiQ script, then the 
system/method initiates a new instance of the HiQ server. 
Where the code comprised in the code node is a MatLab 
script, tben the system/method initiates a new instance of the 
MatLab server. Step 344 may be performed before, during or 
after the compilation process. Where the code comprised in 
the code node is textual code such as Perl, Matbematica, 
Java, etc., then the system/method initiates a new instance of 
an execution program, such as Perl, Mathematica, or Java, 
respectively The code comprised in the code node may also 
comprise textual code such as C, C++, Pascal, Fortran, 
Cobol, etc., and the corresponding application may be an 
interpreter, or a program such as Visual Basic, LabWindows 
CVI, Delphi, etc. 

After compilation of the graphical program, the graphical 
program is then executed. FIG. S illustrates execution of the 
code node in the graphical program, during execution of the 
graphical program, the code node is operable to execute, or 
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invoke execution of, the code comprised in the code node. 
FIG. 5 includes references to the DLL API for certain of the 
steps, indicating the API calls which are made by the code 
node to execute certain of the steps in the flowchart of FIG. 
5 5. 

As shown, in step 362 the method obtains data input to 
terminals of the code node and provides this data iaput to the 
server instance. Thus, the data input provided to terminals of 
the code node are provided to the server instance created in 

10 step 344 of FIG. 4. This is performed using a "Set Vahie" 
command to the API. 

In step 364 the method obtains code comprised within the 
code node of the grq)hical program and provides this code 
to the server instance. Thus, in contrast to the prior art code 
interface node, the code node achially includes the code or 
script contained within the node which is to be executed. In 
step 364 this code or script is provided to the server instance. 
As shown, this code or script is provided using a "Set Code" 
command to the API. 

^ In step 366 the server instance executes the code using the 
input data. Thus, in the case of a HiQ script, the HiQ 
instance executes the HiQ script using the input data pro- 
vided to the code node. In the case of a MatLab script, the 
MatLab instance executes the MatLab script using the iiq)ut 

^ data to the code node. In the case of other types of textual 
code such as Perl, Mathematica, Java, etc., the respective 
application program instance executes the code using the 
input data received by the code node. Where the graphical 
programming system includes the inherent ability to execute 

^ a type of textual code, then a separate server program 
instance may not be required. As shown, step 366 is invoked 
in re^onse to an "Execute Code" call to the API. 
In step 368 the server instance returns the output data. In 

25 other words, execution of the code in step 366 causes the 
server instance to return output data based on execution of 
the code and the input data received. As shown, the graphical 
program operates to obtain the output data returned by the 
server using a "Get Value" command to the API. 

40 In step 370 the graphical programmer receives and uses 
the output data, again in response to the Get Value com- 
mand. This output data is used in the graphical program. For 
example, where the code node includes an output which is 
connected to inputs of one or more other nodes, the output 

45 data is provided to these one or more other nodes for further 
processing. If the code node includes an output which is 
connected to an output indicator, such as through a terminal 
on the diagram, then the output is displayed on the output 
indicator. 

50 In step 372, after completion of the graphical program, the 
server instance is released, as it is no longer needed. 

FIG. 14 is a screen shot illustrating execution of the 
graphical program or VI, wherein the graphical program- 
ming system automatically launches the server program, 

55 e.g., MatLab, and executes the script comprised within the 
code node. 

FIGS. 6 and 7 — Stxipi Node Operation 

The following description describes the current 
60 embodiment, where the code node executes scripts and is 
referred to as a script node. In this current embodiment, two 
possible types of script nodes include a HiQ script node and 
a MatLab script node. Also, in the current embodiment 
described below, the graphical programming system is 
65 referred to as the LabVIEW graphical programming system. 
The present ranbodiment includes a standard interface or 
API used for the code node (or script node) to communicate 
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with respective server programs. Each possible serv^ pro- 
gram has an associated DLL wfaidi implements or executes 
API calls to the respective server program. The code node in 
the graphical programming system communicates with the 
respective DLL corresponding to the respective server pro- 5 
gram. More spedficaUy, the code node in the graphical 
programming system makes calls to the API, which are 
received and executed by the respective DLL The DLL 
communicates with the respective server program in 
response to calls received from the graphical programming 
system. In the preferred embodiment, each respective code 
node or scr^t node has an associated DLL which is specific 
to the respective script node. 

The standard API, also called the DLL API, includes caUs 
such as Get Script, Set Script, Get Value, Set Value, and 
Execute, among others. The API thus performs tasks such as 
launching the script engine, setting or getting saipt text or 
variables, and running the scrq)t. The API is designed to 
resemble the general APIs of script engines that communi- 
cate with the graphical programming system. 

As shown in HG. 6, in the current embodiment, which 
allows HiQ and MatLab scripts, the embodiment includes a 
MalLab script DLL 412 and a HiQ script DLL 414. The 
graphical programming system 402, e.g., Lab VIEW, 
includes code, referred to as script node code 404, which ^ 
makes calls to the appropriate DLL 412 or 414, depending 
on the type of script node being used. The MatLab script 
DLL 412 in turn communicates with an instance of the 
MatLab program 416, which executes the MatLab script. 
The HiQ script DLL 414 in turn communicates with an ^ 
instance of the HiQ program 418 whidi executes the HiQ 
sadpL 

The standard API enables future types of code or scripts 
to be easUy implemented within the graphical programming 
system. In order to implement a new type of code or script, ^5 
the developer adds a new DLL for the respective server 
program, wherein the new DLL implements the standard 
interface for the server program. DLLs for each of the server 
programs are placed in a directory which is available to the 
graphical programming system. ^ 

As described above, when the code node is dropped, the 
graphical programming system loads the appropriate DLL 
for the server program. More specifically, when a specific 
code node or script node is selected from the function palette 
by the user, the graphical programming system receives the 45 
object class and also receives an index into the resource 
string. From this index, the graphical progranmiing system 
obtains the script server identification and the name of the 
DLL to load. Handles to the DLL are stored in a global array 
(FIG. 7). Once the handles are loaded, pointers to DLL 5Q 
functions are also cached. During initiahzation time, each 
script node preferably sets up its DLL function pointer for 
later use. 

Hie run time code of the script node is a C function which 
comprises three parts: convert and copy input data to the 55 
script server; execute the script; and receive and convert 
output data into Lab VIEW. 

Hie new server instance of the server program is not 
initialized until compile time as described above with ref- 
erence to FIG. 4. Thus the user may notice a small amoimt go 
of delay during compile time, due to the requirement of 
launching an instance of the server program. The server 
handle is maintained imtil the next compile. When a recom- 
pile is performed, the server handle is disposed of and 
another handle is reinitialized. 65 

FIG. 7 is a more detailed diagram illustrating the opera- 
tion of a script node making calls to the appropriate DLL to 
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invoke execution of a saipt or code according to the present 
invention. FIG. 7 iUustrates two HiQ script nodes 422A and 
422B, and a MatLab script node 424. As shown, each script 
node 422 and 424 includes a Function Table, referred to as 
"Fnct tbr in FIG. 7, which references a structure 432 or 434 
comprising an array of handles. The anay of handles in turn 
references the appropriate DLL 412 or 414. 

A global variable gScriptDUFnctTable points to the first 
structure 432, and the first structure 432 includes a pointer 
to the next structure 434 in a linked list fashioiL The entries 
in the stmcture 432 and 434 contain handles of the DLL, a 
reference count, a mutex, the name of the script server and 
an array of DLL function pointers. Since the function palette 
menu contains the script node, this information is available 
during Lab VIEW initialization time to dynamically allocate 
the array. Every script node, during the initialization time, 
checks this list to see if its script DLL has already been 
loaded. If so, then the script node sets its table pointer to that 
shared "function pointer bank" and increases the reference 
count. The dispose method for every script node will dec- 
rement the count, and the DLL is removed from memory if 
count is zero. The instance handle to the script server is kept 
inside every node. 

Some script servers are multi-client, i.6., are multi- 
threaded, which means all clients share variables. To guar- 
antee the integrity of sctipt execution, the script DLL uses a 
mutex to protect DLL function calls. 

The following code describes the structures 432 and 434 
used by the script code within LabVIEW to access the 
appropriate DLL. 



emun{ 

klvsnlmplements Version, 
UvsnFirstlmplementedVeision, 

UvsnEmunOu^uts, 

iJvsnNFanctions 

} 

typedcf stnu:t{ 

Int32 re£:x)unt; 

HINSriANCE dllHandlc; 

Mutex scriptRig^ 

CStr scr^Name; 

Void "dllFnct[klvsnNFUnctionsJ 

} ScriptDURQcO^b; 
typdef 8truct{ 

Iiit32 nEntries; 

ScriptDllFnctlkb dUFnct(lt 

} ScriptDUFnctArtay; 
ScriptDllFnctArray gSctq)tDllFnct; 



DLL Interface 

The DLL Interface is as follows. It is noted that portions 
of the DLL interface may not be able to be implemented for 
a specific script server. 

int lvsnImplementsVersion(unsigned inl version); 

unsigned int lvsnFirstImplcm6ntcdVersion(void); 

unsigned int lvsnLastImplementedVersion(void); 

Ivslnstance lvsnInitNew(unsigned int version); 

void lvsnCleanup(lvsnlnstance instance); 

int IvsnSetScript(lvsnInstance instance, const char* text); 

int IvsnGetScript(lvsnInstanoe instance, char* buffer, int 
bufLength); 

int lvsa£ditScript(lvsnInstance instance, HANDLE event, 
HWND parent); 
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void lvsDFiiush£dit(lvsD]iistance instance); 

int lvsnCompile(lvsnInstance instance, unsigned int* 

erroiBegin, unsigned iot* errorEnd, char* 

messageBuffer); 
int lvsnExecute(lvsnInstance instance, unsigned int* 

errorBegin, unsigned iot* errorEnd, char* 

messageBui£fer); 
int lvsnSctValiic(lvsnInstance instance, const char* 

varName, const VARIANT* value); 
int lvsnGetValue(lvsnInstance instance, const char* 

varName, VARIINT* value); 
const char* lvsnGctScriptNamc(void); 
IvsnDebugState lvsnDebugInit(lvsnInstance instance); 
int lvsnDebugStep(lvsnlDstancc instance, IvsnDebugState 

debugState, int how, int* erroiBegin, int* errorEnd, 

char* messageBuffer); 
void lvsnDebugCleanup(lvsnInstance instance, IvsnDe- 
bugState debugState); 
int lvsnEnumInputs(lvsnInstance instance, IvsnEnimi- 

VariablesCallback func, IvsnEoumVariablesData 

funcData); 

int lvsnEnumOutputs(lvsnInstance instance, IvsnEnum- 
VaiiablesCallback func, IvsnEnumVariablesData fimcData); 

Data Conversion between Lab VIEW and the 
program server 

A type conflict error will be returned if data conversion 
between the graphical programming system and the program 
server fails. The implementation includes straight forward, 
conversion, atray dimension change and extraction at the 
OLE variant level Existing OLE variant functions are 
preferably used for the script node. The DLL includes two 
data conversion functions: 
void lvsnRecommend'iypes(Int32 *ne, lDtl6** td);/* this 

function is added to the dll for this purpose */ 
MgErr lvsnSetVariable(lvsnInstancc instance, char* 

varName, int32 dsOffeet, intl6* tdOffeet); 
MgErr lvsnGetVariable(IvsnInstance instance, char* 
varName, inl32 dsOflfeet, intl6* tdOffset); 

During compile time (code generation time), the graphical 
programming system builds a table containing the dataspace 
and type descriptor offset of all the input and output termi- 
nals. The table is located in the data space. 
The offset of this table is passed to the nm time routine, 
typedef struct { 
CStr vName; 
Int32 dsOffeet; 
Int32 tdOfiEset; 

Int32 flag; /*input or output*/ 
} ScriptNodeTermEnlry; 
typedef struct{ 
int32 nEntry; 

} 

ScriptNodeTermEntry scriptTerms[l]; 
The run time routine comprises three sections: copy 
variable to script, execute script, copy output variable bade 
to Lab VIEW. Hie nm time routine returns a non-zero value 
if an error occurs. A routine called GenEnorHandHng is 
compiled into the code to chtck the return value of the soipt 
node nm time routine. 

EMBODIMENTS OF THE INVENTION 

The following discusses various embodiments of the 
present invention for the HiQ and Matab software programs. 
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Both HiQ and MatLab include scripting languages for 
creating scrq)t5. In this descriprion, the code node is referred 
to as a script node. 
HiQ and MATLAB are software programs that enable a 

^ user to organize and visualize real-world math, science, and 
engineering problems. HiQ and MATLAB can be used to 
express numeric formulas elegantly. The present invention 
may be used to enable a user to load and edit HiQ and 
MATLAB scripts into graphical program or block diagram 

10 code so that the graphical program works with their 
advanced mathematics functionality. In the following 
description, the graphical programming system is the Lab- 
VIEW graphical programming system. 

The currently implemented embodiment includes a HiQ 
script node and a MATLAB script node. The HiQ script node 
and the MATLAB script node may be found in the 
Functions»Mathematics»Formula palette, as shown in 
FIG. 8. Tlie user can place a script node on his/her block 
diagram and enter a script according to the syntax of HiQ or 

^ MATLAB. Lab VIEW then communicates with that script 
server engine as described above. When inputs and outputs 
are created on the script node, those values are passed 
between HiQ or MATLAB and LabVIEW. If a script is 
already written, the script can be imported from HiQ or 

^ MATLAB, as discussed below. 

The script node supports the same HiQ or MATLAB data 
types as supported by ActiveX. Because of the nature of the 
HiQ and MATLAB scr^t languages, the user must choose 

^ which LabVIEW data type each terminal should be. This is 
discussed further below. The following two sections, tided 
"Creating a HiQ Script" and "Creating a MATLAB Script", 
descnlje an example for creating a script that does the 
following: 

35 Generates a matrix of random values; 
Plots that information to a graph; 
Displays the graph in either product; and 
Presents the generated random values on the front panel 
in LabVIEW. 

40 

Creating a HiQ Script 

The following instructions are performed to create and 
run a VI that uses a HiQ script 

From the block diagram, the user chooses 
Functions»Mathematics»Formula»HiQ -Script. The 
user then places the node on the block diagram and sizes it 
according to the amount of script desired to include in the 
window. 

With the operating tool, the user enters the script in the 
HiQ script node. For example, the following simple HiQ 
script creates a matrix of random values, plots that infor- 
mation to a graph, and displays the matrix in HiQ. 

a-random({50, 50}); 
55 g»crcateGraph(a); 

creat£view(g, true); 

As noted above, the user may also import a script from an 
external source. 
A HiQ script window may be used to edit, compile, and 

60 run the script direcdy from HiQ to ensure that the script 
behaves properly. In order to use a HiQ script window for 
this purpose, the user right-chcks the HiQ script node and 
selects "Edit In Server". This action launches HiQ, and a 
script window appears containing the HiQ script Within 

65 HiQ, the user right-clicks and chooses compile from the 
pop-up menu. A message window appears telling the user of 
any compile time errors. The user is not required to compile 
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the script explicitly; HiQ compiles the script automatically 
when it is run. The user then right-clicks and chooses Run 
from the pop-up menu. A message ^vindow infomos the user 
of any runtime errors. 

To access HiQ context-sensitive online help, the user 
places the cursor inside any function and prcsses<Fl>. This 
information can be used to help the user build a script 

The user closes the HiQ window to update and return to 
the HiQ script node od the Lab VIEW block diagram. 

In order to add inputs and outputs for variables, the user 
right-clicks the right side of the node frame and selects "Add 
Input** or "Add Output". The user types in "a" to add an 
output for the "a" variable that is included in the HiQ script. 
By default, the node already includes one input and one 
output terminal for the error in and error out parameters. 

The user then should verify the data type of the inputs 
and/or outputs. The error-checking input and output are 
already the correct data type. In HiQ, the defauilt data type 
for any new input or output is Real. The user right-clicks the 
"a" output and selects Choose Type. From the submenu that 
appears, the \iser selects an available data type: Integer, Real, 
Complex, Text, Integer Vector, Real Vector, Complex 
Vector, Integer Matrix, Real Matrix, and Complex Matrix. 
For the "a", output. Real Matrix is chosen for this example. 

Hie user then creates controls and indicators for each 
input and output. The user right-clicks the "a", output 
terminal and selects "Create Indicator". The xiser right-cKcks 
the error out output terminal and selects "Create Indicator". 
Indicators for "a" and "error out" appear on the front panel, 
and terminals appear wired to these outputs on the block 
diagram. 

The user then selects the front panel for viewing and 
resizes his/her "a", indicator to see the generated numbers 
when the VI is run. 

When the user runs the VI, LabVIEW launches HiQ and 
a new HiQ window appears that displays the matrix. The 
values that make up this matrix are displayed in the "a", 
indicator of the front panel in LabVIEW. 

The second parameter in the Create View function (of the 
HiQ script) specifies whether to pause execution of the HiQ 
script while the view is visible. The HiQ script does not 
finish until the user clicks the Continue button in the HiQ 
window to dismiss the view. 

Hie user can change the true parameter to false and re-run 
the VI to see the difference. 

Creating a MATLAB Script 

The following instructions are performed to create and 
run a Vl that uses a MATLAB script. 

From the block diagram, the user chooses 
FuQctions»Mathematics»Formula»MATLAB Script. 
The user places the node on the block diagram, and sizes it 
according to the amount of script desired to include in the 
window. The MATLAB script node appears as shown in 

no. 9. 

Wth the operatitig tool, the user enters a script in the 
MATLAB script node. For example, the following simple 
MATLAB script creates a matrix of random values, plots 
that information to a graph, and displays the matrix in 
MATLAB. 

a=rand(50) 

surf(a) 

As noted above, the user may also import a scripi from an 
external source. 

To add inputs and outputs for variables, the user right- 
cUdcs the right side of the node frame and selects "Add 
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Input" or "Add Output". The user types in "a" to add an 
output for the "a" variable that is included in the MAILAB 
script By default the script node already includes one ii^ut 
and one output terminal for the error in and error out 

5 parameters. 

The user then verifies the data type of the inputs and/or 
outputs. The error-checking input and output are already the 
correct data type. In MATLAB, the default data type for any 
new input or output is Real. The user right-clicks the "a" 

10 output and selects Choose Type. From the submenu that 
appears, the user selects an available data type: Real, 
Complex, Real Vector, Complex Vector, Real Matrix, or 
Complex Matrix. For the "a" output, the user selects Real 
Matrix for this example. 

15 The user then creates controls and indicators for each 
input and output The user right-clicks the "a" output ter- 
minal and selects Create Indicator. The user right-dicks the 
"error out" output terminal and selects "Create Indicator". 
Indicators for "a" and "error out" appear on the front panel, 

20 and terminals appear wired to these outputs on the block 
diagram. 

The \iser then selects the front panel for viewing, and 
resizes the "a" indicator to see the generated numbers when 
the VI is run. 

25 When the VI is run, LabVIEW launches MATLAB and a 
new MAILAB window appears that displays the matrix. 
The values that make up this matrix are displayed in the "a" 
indicator of the front panel in LabVIEW. 

^ Importing or Exporting a Script 

In the currently implemented embodiment, the following 
steps are executed to import a script into a script node in 
UbVIEW. 

1. Right-click the HiQ or MAILAB script node. 

2. Select "Import , . . ". 

3. Choose the file desired to be imported and click Open. 
The script text appears in the node and is editable by the 
user. 

In the currently implemented embodiment, the following 
^ steps are executed to export a sc^pt to LabVIEW from 
MATLAB or HiQ. 

1. Right-click the HiQ or MAILAB script node. 

2. Select "Export . . . ". The Save Script as dialog box 
45 appears. 

3. Enter the desired name to save the file as, or cdioose the 
file desired to be overwritten. 

4. Click Save. 

HiQ and MATLAB script files are actually text files. Text 
50 files usually have the extension ,txt. However, HiQ files have 
a .hqs extension and MATLAB files have a .m extension. 

Choosing a Script Server 
In the currently implemented embodiment, the following 
55 steps are executed to change the server behind the script 
node. 

1. Right-click the HiQ or MAILAB script node. 

2. Select "Choose Script Server»HiQ-Script" or 
"Choose Script Server»MAILAB Script" depending 

60 on whether HiQ or MATLAB is desired. 

Some data types in HiQ are not recognized by MAILAB 
and vice versa. If the script server is changed from one of 
these mathemadcs products to the other after data types have 
been assigned, these data types do not change automatic^ally. 

65 The VI will be broken. When the broken arrow is selected 
or clicked in the toolbar of the VI, the "Error List" window 
reports these incorrect data types. 
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Scrolling through a HiQ or MAILAB Script 

The user can display a scrollbar within the script node by 
right-cliddng the node and selecting "Sbow»Scrollbar'\ A 
scrollbar appears on the right side of the script node. 

Configuring the Data Type of a Terminal 

Both HiQ and MATLAB are loosely typed script lan- 
guages and do oot determine the data type of a variable untQ 
after the script executes. Therefore Lab VIEW cannot deter- 
mine a variable's type in Edit mode. However, Lab VIEW 
docs query the script server to find out possible data types, 
and allows the iiser to dioosc which Lab VIEW data type 
each terminal should be. 

If the user does not conectly configure a variable's data 
type, LabVIEW will produce either an error or incorrect 
information at runtime. 

In the currently implemented embodiment, the following 
steps are executed to change the data type of an input or 
output terminal on a script node. 

1. Right-click the terminal of the input or output. Apop-up 
menu appears. 

2. Select "Choose Type". A list of the available data types 
appears, depending on whether HiQ or MATLAB is 
used. 

3. Choose the preferred data type. 

LabVIEW recognizes all the data types that HiQ and 
MATLAB can use, although they might be named differ- 
ently. 

The table of FIG. 15 shows LabVIEW data types and their 
corresponding data types in HiQ and MATLAB. 

Debugging a HiQ or MATLAB Script 

In the currently implemented embodiment, the following 
programming techniques can be used to allow easier user 
debugging. 

First, the user can write his/her script and run it within the 
native engine (e.g., HiQ or MATLAB) for testing and 
debugging purposes before the script is imported into Lab 
VIEW. In HiQ, the user right-clicks the script node and 
selects "Edit In Server" to debug in a native HiQ script 
window. 

Hie user should also verify data types. When a new input 
or output is created, the user should make sure that the data 
type of the terminal is correct Also, controls and indicators 
for inputs and outputs should be created to enable monitor- 
ing of what values are being passed between LabVIEW and 
the native engine. 

The error-checking parameters can be used for debugging 
information. An indicator for the error out terminal on a 
script node can be created before any VI is run. This allows 
the user to view the generated error information at runtime. 

Error Codes 

The following table explains error messages the user may 
receive at runtime when working with a script node. 
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-continued 



Error Code Error Cods Message Description 

^ 1047 edScxq)tCuUSet\Utte LabVIEW failed to set the value of 

a vanablc to the scrveL 

1048 cdSci^tCaiilGetVWue LabVIEW failed to retrieve the 

value of a variable bam the scrvcL 

1049 edSmptCajuSetScript LabVIEW failed to set a script to 

the server. 

10 1050 edSct^tExecExror LabVIEW encountered an 

execution probteia The server 
returns a string to report the 
problem. 



Error Code Error Code Message Description 

1046 edSc^tChnthiitServcr LabVIEW fi&iled to initiate a new 
session with the server: 



15 Advantageously, the graphical system and method of the 
present invention, which enables a combination of graphical 
programming and text-based programming, has a number of 
benefits. The code node of the present invention allows the 
user to directly view and edit textual source code from 
within a graphical program and invoke execution of the code 
during execution of the graphical program. The benefits 
include a reduction in the development time required to 
create a program, as well as a reduction of the number of 
code defects in the program. Yet another benefit is the 
simplicity of graphical programming, combined with the 

^ ability to incorporate and/or use existing or newly created 
text code in an easy to use format. 

Although the system and method of the present invention 
has been described in connection with the preferred 
embodiment, it is not intended to be limited to the specific 

30 form set forth herein, but on the contrary, it is intended to 
cover such altemativcs, modifications, and equivalents, as 
can be reasonably included within the spirit and scope of the 
invention as defi[ned by the appended claims. 
We claim: 

35 1 . A computer-implemented method for creating a graphi- 
cal program, wherein the graphical program is operable to 
invoke execution of textual code, wherein the method for 
creating the graphical program operates in a computer 
including a di^lay screen and a user input device, the 
4Q method for creating the graphical program comprising: 
displaying on the screen a code node in the graphical 

program in response to user input; 
displaying on the screen textual code comprised in the 
code node in response to user input, wherein the code 
node is operable to invoke execution of the textual code 
comprised in the code node; and 
executing the graphical program, wherein said code node 
invokes execution of said textual code during said 
executing. 

50 2. The computer-implemented method of claim 1, further 
comprising: 

editing the textual code comprised in the code node in 
response to user input prior to said executing the 
graphical program. 
55 3. Tbe computer-implemented method of claim 1, 
wherein said displaying on the screen the textual code 
comprised in the code node comprises importing a textual 
code file into the code node. 

4. The computer-implemented method of claim 1, 
GO wherein said displaying on the screen the textual code 

comprised in the code node comprises receiving user input 
to manually enter the textual code into the code node. 

5. Tlie computer-implemented method of claim 1, further 
comprising: 

65 initiating an instance of a server program, wherein the 
server program is operable to execute the textual code 
comprised in the code node; 
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wfaeiein, during said executiog the graphical piDgram, 
said instance of the scivcr piogram operates to execute 
the textual code comprised in the code oode. 

6. The computer-implemeated method of claim 5, 
wherein said executing the graphical program includes: 

the graphical program providing the textual code to the 
instance of the server program; 

the instance of the server program executing the textual 
code, wherein said executing the textual code produces 
an output; and 

the instance of the server program providing the output to 
the graphical program; 

wherein the output is used during execution of the graphi- 
cal program. 

7. The computer-implemented method of claim 5, 
wherein the code node is connected to receive inputs from 
one or more first nodes in the graphical program; wherein 
said executing the graphical program inchides: 

the one or more first nodes generating a first data output 
which is provided as a first data iiqiut to the code node; 

the graphical program providing the textual code and the 
first data input to the instance of the sender program; 

the instance of the server program executing the textual 
code, wherein the instance of the server program uses 
the first data input in executing the textual code, 
wherein said executing the textual oode produces a 
server program output; and 

the instance of the server program providing the server 
program output to the graphical program; 

wherein the server program output is used during execu- 
tion of the graphical program. 

8. The computer-implemeated method of claim 5, 
releasing the instance of the server program upon comple- 
tion of the graphical program. 

9. The computer-implemented method of claim 1, further 
comprising: 

determining a type of the code node in response to said 
displaying on the screen the code node in the graphical 
program; 

initiating an instance of a server program, wherein the 
server program is operable to execute the textual code 
comprised in the code node, wherein the server pro- 
gram is selected based on the type of the code node; 

wherein, during said executing the graphical program, 
said instance of the server program operates to execute 
the textual code comprised in the cxide node. 

10. The computer-implemented method of claim 9, 
wherein the textual code comprises a script fiom a scripting 
language; 

wherein the code node is a script node selected firom a 
phirahty of script nodes; 

wherein said determining the type of the code node 
comprises determining the type of the scrq)t node; 

wherein said selecting the server program includes select- 
ing a soipting program based on the type of the script 
node. 

11. The computer-implemented method of claim 1, 
wherein the textual code comprises a script fiom a scripting 
language. 

12. The computer-implemented method of claim 1, 
wherein the graphical program comprises a plurality of 
nodes, v\1)erein the method for creating the graphical pro- 
gram further comprises: 

arranging on the screen said plurality of nodes, including 
said code node, to create the graphical program. 
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13. The computer-implemented method of claim 12, 
wherein the method creates a graphical data flow program 
wherein the method for creating the graphical program 
further comprises: 
5 coimecting said plurality of nodes and said code node in 
response to user input, wherein said connecting 
includes connecting said plurality of nodes and said 
code node to provide data flow between said plurality 
of nodes and said code node. 
10 14. The computer-implemented method of claim 1, 
wherein the method for creating the graphical program 
further comprises: 

displaying on the screen a user interface panel in response 
to user input for displaying data input to and/or ou^ut 
from the graphical program. 

15. The computer-implemented method of claim 1, fur- 
ther comprising: 

constructing execution instructions in response to said 

graphical program; and 
executing said execution instructions, wherein said code 

node invokes execution of said textual code during said 

executiog. 

16. A computer-implemented method for creating a 
25 graphical program, wherein the graphical program is oper- 
able to invoke execution of textual code, wherein the method 
for creating the graphical program operates in a computer 
including a display screen and a user input device, the 
method for creating the graphical program comprising: 

30 displaying on the screen a code node in the graphical 
program in response to user input; 
displaying on the screen textual code comprised in the 
code node in response to user input, wherein the code 
node is operable to invoke execution of the textual code 
comprised in the code node, wherein the textual code is 
executable by a server program; 
connecting the code node to receive inputs from one or 
more first nodes in the graphical program; and 
^ executing the graphical program, wherein said code node 
invokes execution of said textual code during said 
executing, wherein said executing the graphical pro- 
gram includes: 

the one or more first nodes generating a first data output 
wtndi is provided as a first data input to the code 
node; 

the graphical program providing the textual code to the 

server program; 
the graphical program providing the fist data input to 

the server program; 
the server program executing the textual code, wherein 
the server program uses the first data input in execut- 
ing the textual code, wherein said executing the 
textual code produces a server program output; and 
the server program providing the server program output 
to the graphical program; 
wherein the server program output is used during execu- 
tion of the graphical program. 

17. The computer-implemented method of claim 16, fur- 
go ther comprising: 

editing the textual code comprised in the oode node in 
response to xiser input prior to said executing the 
graphical program. 

18. A memory medium comprising program instructions 
65 for creating a graphical program, wherein the graphical 

program is operable to invoke execution of textual code, 
wherein the graphical program operates in a computer 
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inchiding a display scree □ and a user iiq)ut device, v^rein 
the program instructions are executable to implement: 
displaying on the screen a code node in the graphical 

program in response to user input; 
displaying on the screen textual code comprised in the ^ 

code node in response to user input, wherein the code 

node is operable to invoke execution of the textual code 

comprised in the code node; and 
executing the graphical program, wherein said code node 

invokes execution of said textual code during said 

executing. 

19. The memory medium of claim 18, wherein the textual 
code comprised in the code node is user editable. 

20. The memory medium of claim 18, wherein said 
displaying on the screen the textual code comprised in the 
code node comprises one of: importing a textual code file 
into the code node; or receiving user input to manually enter 
the textual code into the code node. 

21. The memory medium of claim 18, further comprising: ^ 
initiating an instance of a server program, wherein the 

server program is operable to execute the textual code 
comprised in the code node; 
wherein, during said executing the graphical program, 
said instance of the server program operates to execute 25 
the textual code comprised in the code node, 

22. The memory medium of claim 21, wherein said 
executing the graphical program includes: 

the graphical program providing the textual code to the 
instance of the server program; ^ 

the instance of the server program executing the textual 
code, wherein said executing the textual code produces 
an output; and 

the instance of the server program providing the output to ^5 
the graphical program; 

wherein the output is used during execution of the graphi- 
cal program. 

23. The memory medium of claim 21, wherein the code 
node is connected to receive inputs from one or more first 40 
nodes in the graphical program; wherein said executing the 
graphical program includes: 

the one or more first aodes generating a first data output 
which is provided as a first data input to the code node; 

the graphical program providing the textual code to the 45 
instance of the server program; 

the graphical program providing the first data input to the 
instance of the server program; 

the instance of the server program executing the textual 
code, wherein the instance of the server program uses 
the first data input in executing the textual code, 
wherein said executing the textual code produces a 
server program output; and 

the instance of the server program providing the server 55 
program output to the graphical program; 

wherein the server program output is used during execu- 
tion of the graphical program. 

24. A computer system for creating and executing a 
graphical program, wherein the graphical program is oper- 60 
able to invoke execution of textxial code, the computer 
system comprising: 
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a display screen for displaying a graphical program; 
a user input device for receiving user input; 
a CPU; and 

a memory, wherein the memory stores a graphical pro- 

gramring system which is executable by the CPU for 

creating the graphical program; 
wherein, in response to CPU execution of the graphical 

programming system, the computer system is operable 

to: 

display on the screen a code node in the graphical 
program in response to user input; 

display on the screen textual code comprised in the 
code node in response to tiser input, wherein the code 
node is operable to invoke execution of the textual 
code comprised in the code node; and 

execute the graphical program, wherein the code node 
invokes execution of said textual code during execu- 
tion of the graphical program. 

25. The computer system of claim 24, wherein the textual 
code comprised in the code node is user editable. 

26. The computer system of claim 24, 

wherein the memory further stores a server program, 
wherein the server program is operable to execute the 
textual code comprised in the code node; 

wherein, during execution of the graphical program, an 
instance of the server program operates to execute the 
textual code comprised in the code node. 

27. The computer system of claim 26, 
wherein, in executing the graphical program, 

the graphical program is operable to provide the textual 
code to the instance of the server program; 

the instance of the server program is operable to 
execute the textual code, wherein said executing the 
textual code produces an output; and 

the instance of the server program is operable to 
provide the output to the graphical program; 

wherein the output is used during execution of the 
graphical program. 

28. The computer system of claim 26, wherein the code 
node is connected to receive inputs from one or more first 
nodes in the graphical program; 

wherein, in executing the graphical program, 

the one or more first nodes are operable to generate a 

first data output which is provided as a first data input 

to the code node; 
the graphical program is operable to provide the texmal 

code to the instance of the server program; 
the graphical program is operable to provide the first 

data input to the instance of the server program; 
the instance of the server program is operable to 

execute the textual code, wherein the instance of the 

server program uses the first data ii^ut in executing 

the textual code, wherein said executing the textual 

code produces a server program output; and 
the insance of the server program is operable to provide 

the server program output to the graphical program; 
wherein the server program output is used during 

execution of the graphical program. 

« « « « « 
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